Method and system for controlling key performance indicator parameters of a transportation system

ABSTRACT

The disclosed embodiments illustrate a method and a system for controlling KPI parameters of a transportation system. The method includes extracting historical commuting characteristics of one or more commuters, from a database server over a communication network. The method further includes generating a predictive model based on the extracted historical commuting characteristics. The method further includes generating a service schedule of one or more transportation services of the transportation system. The service schedule of the one or more transportation services may be generated by use of the generated predictive model, based on defined criteria of the transportation system. The method further includes controlling a KPI parameter of the transportation system to attain a desired KPI parameter of the KPI parameter, based on the generated service schedule, when the one or more transportation services are deployed at one or more time stamps.

TECHNICAL FIELD

The presently disclosed embodiments are related, in general, totransportation services. More particularly, the presently disclosedembodiments are related to methods and systems for controlling the keyperformance indicator (KPI) parameters of a transportation system.

BACKGROUND

With an increase in the variety of services that can potentially beoffered to commuters, the decision of which assortment of transportationservices (differentiated by their types, prices, and timings) to offerto customers may become exhaustive and time consuming for serviceproviders. In addition to transportation services, such problems may beencountered in other industries, such as airline industry, hotelindustry, brick and mortar stores, online retailers, and/or the like.Most of the current solutions for such problem work when the number ofdifferent services or products are not on a large scale.

However, in today's competitive era, the different transportationservices offered to the commuters at a given time may affect theirbehavior with respect to the selection of the offered transportationservices. Sometimes, such behavior of the customers may not go well withthe expectations of the service providers, and thus, may affect aservice provider's revenue. In current scenarios, many availablesolutions are static, and therefore, work only when the customer'sbehavior with respect to the various services are known in advance.However, as the number of services encountered in real-time diversify ata very large scale (for instance, at the level of a city or a continentfor transportation services), an automatic and robust technique may berequired to provide a method with low computational complexity to dealwith assortment optimization problems with a large number of services.

Further limitations and disadvantages of conventional and traditionalapproaches will become apparent to one of skill in the art, throughcomparison of described systems with some aspects of the presentdisclosure, as set forth in the remainder of the present application andwith reference to the drawings.

SUMMARY

According to embodiments illustrated herein, there is provided a methodfor controlling key performance indicator (KPI) parameters of atransportation system, by a computing server. The method includesextracting, by a data extracting processor at the computing server,historical commuting characteristics of one or more commuters, from adatabase server over a communication network. The historical commutingcharacteristics of the one or more commuters may be extracted based on afirst user-defined time duration. The method further includesgenerating, by a model generating processor at the computing server, apredictive model based on the extracted historical commutingcharacteristics of the one or more commuters. The method furtherincludes generating, by a schedule generating processor at the computingserver, a service schedule of one or more transportation services of thetransportation system for a second user-defined time duration. Theservice schedule of the one or more transportation services may begenerated by use of the generated predictive model, based on definedcriteria of the transportation system. The defined criteria may compriseone or more parameters based on at least one of a count, a type, and acapacity of the one or more transportation services to be deployed bythe transportation system during the second user-defined time duration.The method further includes controlling, by a processor at the computingserver, a KPI parameter of the transportation system, based on thegenerated service schedule. The KPI parameter may be controlled toattain a desired KPI parameter of the KPI parameter, when the one ormore transportation services are deployed at one or more time stamps inthe second user-defined time duration based on the generated serviceschedule.

According to embodiments illustrated herein, there is provided a systemfor controlling key performance indicator (KPI) parameters of atransportation system. The system may correspond to a computing serverthat includes a data extracting processor. The data extracting processormay be configured to extract historical commuting characteristics of oneor more commuters, from a database server over a communication network.The historical commuting characteristics of the one or more commutersmay be extracted based on a first user-defined time duration. The systemfurther includes a model generating processor that may be configured togenerate a predictive model based on the extracted historical commutingcharacteristics of the one or more commuters. The system furtherincludes a schedule generating processor that may be configured togenerate a service schedule of one or more transportation services ofthe transportation system for a second user-defined time duration. Theservice schedule of the one or more transportation services may begenerated by use of the generated predictive model, based on definedcriteria of the transportation system. The defined criteria may compriseone or more parameters based on at least one of a count, a type, and acapacity of the one or more transportation services to be deployed bythe transportation system during the second user-defined time duration.Further, the system includes a processor that may be configured tocontrol a KPI parameter of the transportation system, based on thegenerated service schedule. The KPI parameter may be controlled toattain a desired KPI parameter of the KPI parameter, when the one ormore transportation services are deployed at one or more time stamps inthe second user-defined time duration based on the generated serviceschedule.

According to embodiments illustrated herein, there is provided acomputer program product for use with a computing device. The computerprogram product comprises a non-transitory computer readable mediumstoring a computer program code for controlling key performanceindicator (KPI) parameters of a transportation system. The computerprogram code is executable by one or more processors in a computingdevice to extract historical commuting characteristics of one or morecommuters, from a database server over a communication network. Thehistorical commuting characteristics of the one or more commuters may beextracted based on a first user-defined time duration. The computerprogram code is further executable by the one or more processors togenerate a predictive model based on the extracted historical commutingcharacteristics of the one or more commuters. The computer program codeis further executable by the one or more processors to generate aservice schedule of one or more transportation services of thetransportation system for a second user-defined time duration. Theservice schedule of the one or more transportation services may begenerated by use of the generated predictive model, based on definedcriteria of the transportation system. The defined criteria may compriseone or more parameters based on at least one of a count, a type, and acapacity of the one or more transportation services to be deployed bythe transportation system during the second user-defined time duration.The computer program code is further executable by the one or moreprocessors to control a KPI parameter of the transportation system,based on the generated service schedule. The KPI parameter may becontrolled to attain a desired KPI parameter of the KPI parameter, whenthe one or more transportation services are deployed at one or more timestamps in the second user-defined time duration based on the generatedservice schedule.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings illustrate the various embodiments of systems,methods, and other aspects of the disclosure. Any person with ordinaryskills in the art will appreciate that the illustrated elementboundaries (e.g., boxes, groups of boxes, or other shapes) in thefigures represent one example of the boundaries. In some examples, oneelement may be designed as multiple elements, or multiple elements maybe designed as one element. In some examples, an element shown as aninternal component of one element may be implemented as an externalcomponent in another, and vice versa. Furthermore, the elements may notbe drawn to scale.

Various embodiments will hereinafter be described in accordance with theappended drawings, which are provided to illustrate the scope and not tolimit it in any manner, wherein like designations denote similarelements, and in which:

FIG. 1 is a block diagram that illustrates an exemplary systemenvironment, in which various embodiments of the disclosed method andsystem to control the KPI parameters of a transportation system can beimplemented, in accordance with at least one embodiment;

FIG. 2 is a block diagram that illustrates an exemplary applicationserver to control the KPI parameters of a transportation system, inaccordance with at least one embodiment;

FIG. 3 is a flowchart that illustrates exemplary operations to controlthe KPI parameters of a transportation system, in accordance with atleast one embodiment;

FIG. 4A is a block diagram that illustrates an exemplary scenario tocontrol the KPI parameters of a transportation system in an offlinesetting, in accordance with at least one embodiment; and

FIG. 4B is a block diagram that illustrates an exemplary scenario tocontrol the KPI parameters of a transportation system in an onlinesetting, in accordance with at least one embodiment.

DETAILED DESCRIPTION

The present disclosure is best understood with reference to the detailedfigures and description set forth herein. Various embodiments arediscussed below with reference to the figures. However, those skilled inthe art will readily appreciate that the detailed descriptions givenherein with respect to the figures are simply for explanatory purposesas the methods and systems may extend beyond the described embodiments.For example, the teachings presented and the needs of a particularapplication may yield multiple alternative and suitable approaches toimplement the functionality of any detail described herein. Therefore,any approach may extend beyond the particular implementation choices inthe following embodiments described and shown.

References to “one embodiment,” “at least one embodiment,” “anembodiment,” “one example,” “an example,” “for example,” and so on,indicate that the embodiment(s) or example(s) may include a particularfeature, structure, characteristic, property, element, or limitation,but that not every embodiment or example necessarily includes thatparticular feature, structure, characteristic, property, element, orlimitation. Furthermore, repeated use of the phrase “in an embodiment”does not necessarily refer to the same embodiment.

Definitions: The following terms shall have, for the purposes of thisapplication, the meanings set forth below.

A “commuter-computing device” may refer to a computer, a device (thatincludes one or more processors/microcontrollers and/or any otherelectronic components), or a system (that performs one or moreoperations according to one or more programming instructions/codes)associated with a commuter. The commuter may correspond to anindividual, who may be interested in renting a transportation service,such as a bus or a car, to travel from one location to another location.Based on an input provided by the commuter, the commuter-computingdevice may present a graphical user interface (GUI) to the commuter forfacilitating real-time (or non-real time) transportation servicesprovided by a service provider. Based on the presented GUI, the commutermay share preferences for one or more transportation services. Further,the commuter may provide input to select, accept, or reject the one ormore transportation services provided by a service provider. Examples ofthe commuter-computing device may include, but are not limited to, alaptop, a personal digital assistant (PDA), a mobile device, asmartphone, and a tablet computer (e.g., iPad® and Samsung Galaxy Tab®).

A “service provider-computing device” may refer to a computer, a device(that includes one or more processors/microcontrollers and/or any otherelectronic components), or a system (that performs one or moreoperations according to one or more programming instructions/codes)associated with a service provider. The service provider may correspondto an individual, who is facilitating one or more transportationservices (e.g., buses, cars, motor bikes, and so on) to one or morecommuters for travel between at least two locations. The serviceprovider-computing device may present a GUI to the service provider fordisplaying one or more travel requests received from one or morecommuter-computing devices. Further, the service provider-computingdevice may present another GUI to the service provider for displaying aschedule of one or more transportation services. Further, the serviceprovider-computing device may present yet another GUI to the serviceprovider for displaying the real-time status of one or more KPIparameters, such as revenue or profit, based on deployment of the one ormore transportation services according to the schedule. The serviceprovider may further utilize the service provider-computing device toinput one or more offerings, such as a discounted service price, thatmay be offered to one or more commuters either for a real-time serviceor a non-real time service. Examples of the service provider-computingdevice may include, but are not limited to, a laptop, a PDA, a mobiledevice, a smartphone, and a tablet computer (e.g., iPad® and SamsungGalaxy Tab®).

“Transportation system” may correspond to transport facilities that mayoffer one or more means of transport to a commuter to travel from onelocation to another location. In an embodiment, the transportationsystem may correspond to a public transportation system, a privatetransportation system, a shared transportation system, and/or the like.Examples of various transportation systems may include one or moretransportation services such as, but are not limited to, a bustransportation service, a train transportation service, a cartransportation service, a motor bike transportation service, or anairplane transportation services. Hereinafter, “transportation system”and “transportation agency” may be interchangeably used.

A “route” may refer to a path that may be traversed by a vehicle, whilein transit. In an embodiment, the route may include a plurality ofstations that may come in a defined order in the route. For example, acity bus travels from Harlem to East Village in New York. Thus, the pathfrom Harlem to East Village may correspond to the route with Harlem andEast Village being the plurality of stations. Further, the plurality ofstations may include at least one pick-up station and one drop-offstation.

A “vehicle” may refer to a type of transportation services that maytransport one or more commuters and/or cargos between two or morestations along a route of transit. In an embodiment, the one or morecommuters may share the vehicle with one or more other commuters duringthe transit along the route. In an embodiment, the vehicle may beinstalled with a vehicle-computing device and one or more sensors, suchas a global positioning system. In an embodiment, the vehicle maycorrespond to a bus, a truck, a car, a ship, an airplane, a motor bike,and/or the like.

A “commuter” may refer to an individual who may wish to avail atransportation service to travel from a source station to a destinationstation among a plurality of stations along a route. For example, anindividual wants to travel from “New Delhi” to “Gurgaon.” The individualmay avail a transportation service, such as a bus service, for thetravel. The individual may board a city bus, which is in transit from“New Delhi” to “Gurgaon,” from “New Delhi.” The individual may furtheralight the city bus at “Gurgaon.” The individual may have to pay acertain service fare for availing the transportation service. In thisscenario, the individual may correspond to the commuter.

A “service provider” may refer to an entity who may wish to provide atransportation service to one or more commuters to travel from a sourcestation to a destination station among a plurality of stations along aroute, based on a request provided by the one or more commuters. Forexample, a commuter utilizes an application or a web page on acommuter-computing device to input a request to travel from “a firststation” to “a second station.” Based on the request, the serviceprovider may utilize the service provider-computing device to provideone or more available transportation services to the commuter.

A “KPI parameter” may refer to a parameter that may be used to evaluateone or more factors that define the growth or success of an entity, suchas a transportation agency. Examples of the KPI parameter may include atleast one of, but are not limited to, net revenue generated by one ormore transportation services, profit earned by the transportation agencybased on deployment of the one or more transportation services along oneor more routes at one or more time instances, and count of commuterscarried by the one or more transportation services. In an embodiment,the service provider associated with the transportation agency may wishto continuously optimize the KPI parameter for the continuous growth ofthe transportation agency. For example, the optimization of the KPIparameter may refer to the maximization of the revenue generated or amaximization of the profit earned.

“Historical commuting characteristics” may refer to commuting behaviorsor patterns of one or more commuters, who may have traveled between atleast two locations using one or more transportation services in thepast. The commuting behavior or pattern may be dependent upon at leastone of, but not limited to, a source station, a destination station, atravel time, a travel cost, a service capacity, and a travel route. Forexample, “25 commuters” board a bus at 9 AM for five days a week (e.g.,Monday to Friday) to travel from “station-A” to “station-B.” The “25commuters” board the bus in an event the bus is not overcrowded and theservice price is not more than “USD 5.” In such scenario, the historicalcommuting characteristics of the “25 commuters” may includecharacteristics, such as “source station: station-A,” “destinationstation: station-B,” “travel time: 9 AM,” “Frequency of travel: Mondayto Friday,” “travel constraint: avoid overcrowd bus,” and “serviceprice: less than USD 5.”

A “predictive model” may refer to a random utility choice model, whichmay enable prediction of a schedule of one or more transportationservices at one or more time instances so as to optimize one or more KPIparameters of a transportation agency. In an embodiment, the predictivemodel may be generated based on historical commuting characteristics ofone or more commuters. The predictive model may employ one or moretechniques such as, but not limited to, one or more statisticaltechniques, one or more natural language processing techniques, one ormore neural network techniques, and/or one or more machine learningtechniques to predict the schedule of the one or more transportationservices. For example, the predictive model may correspond to amultinomial logit (MNL) model that may be configured to capture thehistorical commuting characteristics of the one or more commuters. TheMNL model may quickly solve an assortment optimization problem, forexample, five times faster than integer programming algorithms.

A “service schedule” may refer to a plan or a timetable of carrying outone or more services or processes. For example, a service schedule for atransportation agency may include one or more time instances at whichone or more transportation services may be deployed for transit alongone or more routes. In an embodiment, the service schedule for thetransportation agency may be generated based on at least historicalcommuting characteristics of one or more commuters, a defined timeduration, an availability of one or more types of the one or moretransportation services for the defined time duration, and/or a capacityin each of the one or more types of the one or more transportationservices.

A “first defined time duration” may refer to a time interval that isdefined by an individual, for example, a service provider associatedwith a transportation agency. The service provider may define the firsttime duration either in real time or near-real time. In an embodiment, acomputing server may extract historical commuting characteristics of oneor more commuters based on the first defined time duration. For example,the extraction of the historical commuting characteristics of the one ormore commuters from a storage server may be limited by the first definedtime duration. Hereinafter, “first defined time duration,” and “firstuser-defined time duration” may be interchangeably used.

A “second defined time duration” may refer to a time interval that isdefined by an individual, for example, a service provider associatedwith a transportation agency. The service provider may define the secondtime duration either in real time or near-real time. In an embodiment, acomputing server may generate a service schedule for the transportationagency based on at least the second defined time duration. The seconddefined time duration may include one or more time stamps at which oneor more transportation services may transit along one or more routes.

“Defined criteria of a transportation system” may refer to a set ofrules, instructions, measures, or standards that are defined by anindividual, such as a service provider associated with thetransportation system, that may be utilized to generate a serviceschedule. The defined criteria of the transportation system may compriseone or more parameters based on at least one of a count, a type, and acapacity of the one or more transportation services to be deployed bythe transportation system during a second defined time duration.

“Service capacity” may refer to the maximum count of commuters atransportation service, for example, a bus can accommodate. For example,a city bus can accommodate a maximum of 15 commuters at any given timeinstant. In this scenario, the service capacity of the city bus is “15.”Hereinafter, “service capacity,” “vehicle capacity,” and “transportcapacity” may be interchangeably used.

“Service cost” may refer to a monetary value that a commuter may have topay to an individual, such as a service provider, in exchange for usinga transportation service, for example, a car. Hereinafter, “servicecost” and “travel cost” may be interchangeably used.

“Travel time” may refer to the time duration required to a travelbetween at least two locations, such as a source location and adestination location, by a transportation service, such as a bus.Hereinafter, “travel time” and “service time” may be interchangeablyused.

A “source station” may refer to a location from where a journey startsalong a route. The source station may be associated with atransportation service and a commuter. In an embodiment, the sourcestation of the commuter and the transportation service may or may not besame. For example, a transportation service provided by a vehicle, suchas a bus, originates from “station-A” and terminates at “station-B.”There are five intermediate stations between “station-A” and“station-B,” for example, “station-1,” “station-2,” “station-3,”“station-4,” and “station-5.” Therefore, in an event the commuterboarded the bus at “station-A,” then the source station of the commuterand the transportation service is the same. However, in an event thecommuter boarded the bus at “station-2,” the source station of thecommuter and the transportation service is not the same. Hereinafter,“source station” and “source location” may be interchangeably used.

A “destination station” may refer to a location at which an ongoingjourney terminates. The destination station may be associated with atransportation service and a commuter. In an embodiment, the destinationstation of the commuter and the transportation service may or may not besame. For example, a transportation service, such as a bus, originatesfrom “station-A” and terminates at “station-B.” There are fiveintermediate stations between “station-A” and “station-B,” for example,“station-1,” “station-2,” “station-3,” “station-4,” and “station-5.”Therefore, in an event the commuter ends the journey and gets down fromthe bus at “station-B,” the destination station of the commuter and thetransportation service is the same. However, in an event the commuterends the journey and gets down from the bus at “station-4,” the sourcestation of the commuter and the transportation service is not the same.Hereinafter, “destination station” and “destination location” may beinterchangeably used.

A “commuter preference vector” may refer to a set of numerical values,in which each numerical value defines a preference of a commuter fortravel along a route by a transportation service. In an embodiment, thecommuter preference vector may be generated based on historicalcommuting characteristics of one or more commuters.

A “service cost vector” may refer to a set of numerical values, in whicheach numerical value defines a travel price for traveling between asource location and a destination location by a transportation service.In an embodiment, the service cost vector may be generated based on thetravel cost associated with each of the one or more transportationservices of a transportation system.

FIG. 1 is a block diagram that illustrates an exemplary systemenvironment, in which various embodiments of the disclosed method andsystem to control KPI parameters of a transportation system can beimplemented. With reference to FIG. 1, there is shown a systemenvironment 100 that includes a commuter-computing device 102, a serviceprovider-computing device 104, a database server 106, and an applicationserver 108. The system environment 100 further includes a communicationnetwork 110. Various devices in the system environment 100 may beinterconnected over the communication network 110, as shown. FIG. 1shows, for simplicity, one commuter-computing device, such as thecommuter-computing device 102, one service provider-computing device,such as the service provider-computing device 104, one database server,such as the database server 106, and one application server, such as theapplication server 108. However, it will be apparent to a person havingordinary skills in the art that the disclosed embodiments may also beimplemented using multiple commuter-computing devices, multiple serviceprovider-computing devices, multiple database servers, and multipleapplication servers without departing from the scope of the disclosure.

The commuter-computing device 102 may refer to a computing device thatincludes one or more processors in communication with one or more memoryunits. Further, in an embodiment, the one or more processors may beoperable to execute one or more sets of computer-readable code,instructions, programs, or algorithms that are stored in the one or morememory units to perform one or more operations. The commuter-computingdevice 102 may be further communicatively coupled to other devices overthe communication network 110. The commuter-computing device 102 may beassociated with a user, such as a commuter or a traveler, who may beinterested in renting a transportation service, such as a bus or a car,to travel from one location to another location. In such scenario, thecommuter may utilize the commuter-computing device 102 to input a travelrequest. The travel request may comprise travel-related information,such as information associated with a source location, a destinationlocation, a travel time, a waiting time, a travel route, and/or thelike. The commuter may further utilize the commuter-computing device 102to provide one or more preferences for one or more transportationservices, such as a bus, a car, a motor bike, and/or the like. The oneor more preferences may indicate preferences for one or more types ofthe one or more transportation services. For example, for atransportation service, such as a car, the various types may correspondto a mini car, a compact car, a hatchback car, a mid-size car, a sedancar, an executive car, a premium car, and/or the like. Thecommuter-computing device 102 may further transmit the travel requestand the one or more preferences provided by the commuter to theapplication server 108, via the communication network 110.

The commuter-computing device 102 may further include a display screenthat may be configured to display one or more travel options in responseto the travel request of the commuter, at a graphical user interface(GUI) rendered by the application server 108 over the communicationnetwork 110. For example, the application server 108 may render a GUIdisplaying the one or more types of one or more available transportationservices, a service cost for using each of the one or more availabletransportation services, expected time duration for reaching thedestination location, and/or the like. Based on the displayedinformation on the GUI, the commuter may utilize the commuter-computingdevice 102 to either accept or reject the one or more travel optionsrendered at the GUI.

Examples of the commuter-computing device 102 may include, but are notlimited to, a personal computer, a laptop, a PDA, a mobile device, atablet, or other such computing devices.

The service provider-computing device 104 may refer to a computingdevice that includes one or more processors in communication with one ormore memory units. Further, in an embodiment, the one or more processorsmay be operable to execute one or more sets of computer-readable code,instructions, programs, or algorithms that are stored in the one or morememory units to perform one or more operations. The serviceprovider-computing device 104 may be further communicatively coupled toother devices over the communication network 110. The serviceprovider-computing device 104 may be associated with a user, such as aservice provider of a transportation system, who may be involved infacilitating the one or more transportation services to one or morecommuters. The service provider may utilize the serviceprovider-computing device 104 to view one or more travel requestsreceived from one or more commuter-computing devices, such as thecommuter-computing device 102. Based on the received one or more travelrequests, the service provider may utilize the serviceprovider-computing device 104 to provide a schedule request that may betransmitted to the application server 108 over the communication network110.

The service provider-computing device 104 may further include a displayscreen that may be configured to display a service schedule generated bythe application server 108. Further, the display screen may displayreal-time status of the one or more transportation services. The displayscreen may further display the real-time status of one or more KPIparameters, such as revenue or profit, which may have been attainedbased on deployment of the one or more transportation services accordingto the generated service schedule.

Examples of the service provider-computing device 104 may include, butare not limited to, a personal computer, a laptop, a PDA, a mobiledevice, a tablet, or other such computing devices.

The database server 106 may refer to a computing device or a storageserver that may be communicatively coupled to the communication network110. In an embodiment, the database server 106 may be configured toperform one or more database operations. The one or more databaseoperations may include one or more of, but are not limited to,receiving, storing, processing, and transmitting one or more queries,data, or content. The one or more queries, data, or content may bereceived/transmitted from/to various components of the systemenvironment 100. For example, the database server 106 may be configuredto store the one or more travel requests and the one or more preferencesof the one or more commuters. The database server 106 may further storehistorical commuting characteristics of the one or more commuters, whomay have traveled between at least two locations using the one or moretransportation services in the past. The historical commutingcharacteristics may be dependent upon at least one of, but not limitedto, a source location, a destination location, a travel time, a travelcost, a service capacity, and a travel route. Further, in an embodiment,the database server 106 may store historical demand data for the one ormore transportation services. The historical demand data may compriseinformation pertaining to a demand for the one or more transportationservices along one or more routes. The historical demand data may bereceived from one or more data acquisition devices installed at each ofa plurality of stations along the one or more routes, over thecommunication network 110. Such historical demand data may constitutethe historical commuting characteristics. The database server 106 may befurther configured to store the one or more KPI parameters specified bythe service provider. The one or more KPI parameters may be correspondto one or more valuation parameters that are utilized to define thegrowth of the transportation system. For example, the one or more KPIparameters may correspond to one or more of, but are not limited to, netrevenue generated and net profit earned by the transportation systembased on deployment of the one or more transportation services along theone or more routes at one or more time instances. The one or more KPIparameters may further correspond to a count of commuters carried by theone or more transportation services. In an embodiment, the databaseserver 106 may be configured to receive one or more queries from theapplication server 108 for the retrieval of the one or more travelrequests, the one or more preferences, the historical commutingcharacteristics, the one or more KPI parameters, and/or the like.

For querying the database server 106, one or more querying languages,such as, but not limited to, SQL, QUEL, and DMX, may be utilized. In anembodiment, the database server 106 may connect to the applicationserver 108, using one or more protocols, such as, but not limited to,the ODBC protocol and the JDBC protocol. In an embodiment, the databaseserver 106 may be realized through various technologies such as, but notlimited to, Microsoft® SQL Server, Oracle®, IBM DB2®, Microsoft Access®,PostgreSQL®, MySQL®, and SQLite®.

The application server 108 may refer to an electronic device, acomputing device, or a software framework hosting an application or asoftware service that may be communicatively coupled to thecommunication network 110. In an embodiment, the application server 108may be implemented to execute one or more sets of instructions,programs, routines, scripts, code, and/or the like, stored in one ormore memory units for supporting the hosted application or the softwareservice. In an embodiment, the hosted application or the softwareservice may be configured to perform one or more operations forcontrolling the one or more KPI parameters of the transportation system.

The application server 108 may be configured to query the databaseserver 106 to retrieve the historical commuting characteristics of theone or more commuters. The retrieval of the historical commutingcharacteristics may be limited by a first defined time duration. In analternate embodiment, the application server 108 may receive thehistorical commuting characteristics from the one or more dataacquisition devices installed at each of the plurality of stations. Theone or more data acquisition devices may correspond to one or morecomputerized ticketing systems and one or more image capturing devicesinstalled at each of the plurality of stations and the one or moretransportation services. The retrieval of the historical commutingcharacteristics has been described in detail, for example, in FIG. 3.

Further, in an embodiment, the application server 108 may be configuredto generate a predictive model. The predictive model may be generatedbased on the retrieved (or received) historical commutingcharacteristics of the one or more commuters. The predictive model maycorrespond to a random utility choice model. For example, the predictivemodel may correspond to an MNL model that may be configured to capturethe historical commuting characteristics to generate the serviceschedule of the one or more transportation services. The generation ofthe predictive model has been described in detail, for example, in FIG.3, FIG. 4A, and FIG. 4B.

In an embodiment, the application server 108 may be configured togenerate the service schedule of the one or more transportation servicesfor a second defined time duration, by use of the generated predictivemodel, for example, the MNL model trained on the historical commutingcharacteristics. The generation of the service schedule of the one ormore transportation services may be further based on criteria of thetransportation system defined by the service provider. The definedcriteria may comprise one or more parameters based on at least one of acount, a type, and a capacity of the one or more transportationservices. The generation of the service schedule has been described indetail, for example, in FIG. 3, FIG. 4A, and FIG. 4B.

In an embodiment, the application server 108 may be configured tocontrol the one or more KPI parameters of the transportation system,based on the generated service schedule, when the one or moretransportation services may be deployed at one or more time stamps inthe second user-defined time duration. The one or more KPI parametersmay be controlled to attain at least one or more desired KPI parametersspecified by the service provider. In another embodiment, theapplication server 108 may generate the service schedule by use of thepredictive model, such that the one or more desired KPI parameters maybe attained when the one or more transportation services are deployedbased on the generated service schedule. The controlling of the one ormore KPI parameters has been described in detail, for example, in FIG.3, FIG. 4A, and FIG. 4B.

In an embodiment, the application server 108 may further receivereal-time feedback data from a service provider-computing device 104associated with the service provider of the transportation system overthe communication network 110. The received real-time feedback data maybe associated with a current status of the one or more KPI parametersthat is obtained based on the deployment of the one or moretransportation services at a time stamp in the second defined timeduration. In an event the one or more KPI parameters are less than theone or more desired KPI parameters, the application server 108 mayupdate the generated predictive model based on the received real-timefeedback data. The application server 108 may further update thegenerated service schedule at one or more other time stamps in thesecond defined time duration, based on the updated predictive model. Theupdating of the predictive model and the service schedule have beendescribed in detail, for example, in FIG. 3, FIG. 4A, and FIG. 4B.

The application server 108 may be realized through various types ofapplication servers, such as, but not limited to, a Java applicationserver, a .NET framework application server, a Base4 application server,a PHP framework application server, or any other application serverframework.

A person having ordinary skill in the art will appreciate that the scopeof the disclosure is not limited to realizing the application server 108and the database server 106 as separate entities. In an embodiment, thefunctionalities of the database server 106 may be integrated into theapplication server 108, without departing from the scope of thedisclosure. Further, in an embodiment, the application server 108 may berealized as an application program installed and/or running on theservice provider-computing device 104, without limiting the scope of thedisclosure.

The communication network 110 may correspond to a medium through whichqueries, content, and messages flow among various devices, such as thecommuter-computing device 102, the service provider-computing device104, the database server 106, and the application server 108, of thesystem environment 100. Examples of the communication network 110 mayinclude, but are not limited to, a the Internet, a cloud network, a LongTerm Evolution (LTE) network, Wireless Fidelity (Wi-Fi) network, aWireless Area Network (WAN), a Local Area Network (LAN), or aMetropolitan Area Network (MAN). Various devices in the systemenvironment 100 can connect to the communication network 110 inaccordance with various wired and wireless communication protocols.Examples of such wired and wireless communication protocols may include,but are not limited to, at least one of a Transmission Control Protocoland Internet Protocol (TCP/IP), User Datagram Protocol (UDP), HypertextTransfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE,IEEE 802.11, light fidelity (Li-Fi), 802.16, IEEE 802.11s, IEEE 802.11g,multi-hop communication, wireless access point (AP), device to devicecommunication, cellular communication protocols, or Bluetooth (BT)communication protocols, or a combination thereof.

FIG. 2 is a block diagram that illustrates an exemplary applicationserver to control the KPI parameters of a transportation system, inaccordance with at least one embodiment. FIG. 2 has been described inconjunction with FIG. 1. With reference to FIG. 2, there is shown ablock diagram of the exemplary application server, such as theapplication server 108 that may include one or more circuits to controlthe KPI parameters of the transportation system. The one or morecircuits may correspond to a processor 202, a data extracting processor204, a model generating processor 206, a schedule generating processor208, a memory 210, an input/output (I/O) unit 212, and a transceiver214. With reference to FIG. 2, there is further shown the communicationnetwork 110 (FIG. 1).

In accordance with an embodiment, the processor 202 may becommunicatively coupled to the data extracting processor 204, the modelgenerating processor 206, the schedule generating processor 208, thememory 210, the I/O unit 212, and the transceiver 214. The transceiver214 may be configured to communicate with the commuter-computing device102, the service provider-computing device 104, and the database server106, via the communication network 110, under the control of theprocessor 202.

The processor 202 may include suitable logic, circuitry, code, and/orinterfaces that may be configured to execute one or more instructionsstored in the memory 210. The processor 202 may further include acomputational and control unit (not shown). The computational andcontrol unit may be configured to perform one or more mathematical andlogical operations, and may further control the operations. Theprocessor 202 may execute one or more sets ofinstructions/programs/code/scripts stored in the memory 210 to performone or more operations for real-time management of the one or more KPIparameters of the transportation system. In an embodiment, the processor202 may be configured to monitor and control the one or more KPIparameters in an event the one or more transportation services aredeployed based on the service schedule generated by the schedulegenerating processor 208. The processor 202 may be implemented based ona number of processor technologies known in the art. Examples of theprocessor 202 may include, but are not limited to, an X86-basedprocessor, a Reduced Instruction Set Computing (RISC) processor, anApplication-Specific Integrated Circuit (ASIC) processor, a ComplexInstruction Set Computing (CISC) processor, and/or other processors orcontrol circuits.

The data extracting processor 204 may include suitable logic, circuitry,code, and/or interfaces that may be configured to execute one or moreinstructions stored in the memory 210. The data extracting processor 204may execute one or more sets of instructions/programs/code/scriptsstored in the memory 210 to perform one or more operations. For example,the data extracting processor 204 may be configured to extract thehistorical commuting characteristics of the one or more commuters fromthe database server 106. The data extracting processor 204 may beimplemented based on a number of processor technologies known in theart. Examples of the data extracting processor 204 may include, but arenot limited to, an X86-based processor, a RISC processor, an ASICprocessor, a CISC processor, and/or other processors or controlcircuits.

The model generating processor 206 may include suitable logic,circuitry, code, and/or interfaces that may be configured to execute oneor more instructions stored in the memory 210. The model generatingprocessor 206 may execute one or more sets ofinstructions/programs/code/scripts stored in the memory 210 to performone or more operations. For example, the model generating processor 206may be configured to generate a random utility choice model, such as theMNL model, that may capture the historical commuting characteristics ofthe one or more commuters. The model generating processor 206 may beimplemented based on a number of processor technologies known in theart. Examples of the model generating processor 206 may include, but arenot limited to, an X86-based processor, a RISC processor, an ASICprocessor, a CISC processor, and/or other processors or controlcircuits.

The schedule generating processor 208 may include suitable logic,circuitry, code, and/or interfaces that may be configured to execute oneor more instructions stored in the memory 210. The schedule generatingprocessor 208 may execute one or more sets ofinstructions/programs/code/scripts stored in the memory 210 to performone or more operations. For example, the schedule generating processor208 may be configured to generate the service schedule of the one ormore transportation services for the second defined time duration, byuse of the MNL model, based on the defined criteria of thetransportation system. The schedule generating processor 208 may befurther configured to update the generated service schedule to obtain anupdated service schedule, based on the real-time feedback data receivedfrom the service provider-computing device 104. The schedule generatingprocessor 208 may be implemented based on a number of processortechnologies known in the art. Examples of the schedule generatingprocessor 208 may include, but are not limited to, an X86-basedprocessor, a RISC processor, an ASIC processor, a CISC processor, and/orother processors or control circuits.

Though the data extracting processor 204, the model generating processor206, and the schedule generating processor 208 are depicted as separateentities (FIG. 2), a person skilled in the art will appreciate that thescope of the disclosure is not limited to realizing the functionality ofthe data extracting processor 204, the model generating processor 206,and the schedule generating processor 208 by the processor 202. In anembodiment, the data extracting processor 204, the model generatingprocessor 206, and the schedule generating processor 208 may beimplemented within the processor 202 without departing from the spiritof the disclosure. Further, a person skilled in the art will understandthat the scope of the disclosure is not limited to realizing the dataextracting processor 204, the model generating processor 206, and theschedule generating processor 208 as hardware components. In anembodiment, the data extracting processor 204, the model generatingprocessor 206, and the schedule generating processor 208 may beimplemented as a software module included in computer program code(stored in the memory 210), which may be executable by the processor 202to perform the functionalities of the data extracting processor 204, themodel generating processor 206, and the schedule generating processor208.

The memory 210 may comprise suitable logic, circuitry, interfaces,and/or code that may be configured to store one or more machine codesand/or computer programs having at least one code section executable bythe processor 202, the data extracting processor 204, the modelgenerating processor 206, the schedule generating processor 208, the I/Ounit 212, and the transceiver 214. The memory 210 may store the one ormore sets of instructions that are executable by the processor 202, thedata extracting processor 204, the model generating processor 206, theschedule generating processor 208, the I/O unit 212, and the transceiver214. In an embodiment, the memory 210 may include one or more buffers(not shown). The one or more buffers may be configured to temporarilystore the extracted historical commuting characteristics of the one ormore commuters. The one or more buffers may further temporarily storethe one or more KPI parameters and the associated minimum desiredvalues, the defined criteria, current operation status of the one ormore transportation services, current service demand, and/or the like.Examples of some commonly known memory implementations may include, butare not limited to, a random access memory (RAM), a read only memory(ROM), a hard disk drive (HDD), and a secure digital (SD) card. In anembodiment, the memory 210 may include the one or more machine codes,and/or computer programs that are executable by the processor 202, thedata extracting processor 204, the model generating processor 206, andthe schedule generating processor 208 to perform specific operations forcontrolling KPI parameters of the transportation system. It will beapparent to a person having ordinary skills in the art that the one ormore instructions stored in the memory 210 may enable the hardware ofthe application server 108 to perform the one or more operations,without deviating from the scope of the disclosure.

The I/O unit 212 may comprise suitable logic, circuitry, interfaces,and/or code that may be configured to provide an output to a serviceprovider of the transportation system. The I/O unit 212 comprisesvarious input and output devices that are configured to communicate withthe processor 202, the data extracting processor 204, the modelgenerating processor 206, and the schedule generating processor 208.Examples of the input devices include, but are not limited to, akeyboard, a mouse, a joystick, a touch screen, a microphone, a camera,and/or a docking station. Examples of the output devices include, butare not limited to, a display screen and/or a speaker.

The transceiver 214 may comprise suitable logic, circuitry, interfaces,and/or code that may be configured to receive/transmit the one or morequeries, requests, user preferences, historical commutingcharacteristics and/or other information from/to one or more computingdevices or servers (e.g., the commuter-computing device 102, the serviceprovider-computing device 104, and/or the database server 106) over thecommunication network 110. The transceiver 214 may be designed using oneor more known technologies to support wired or wireless communicationwith the communication network 110. In an embodiment, the transceiver214 may include circuitry, such as, but not limited to, an antenna, aradio frequency (RF) transceiver, one or more amplifiers, a tuner, oneor more oscillators, a digital signal processor, a Universal Serial Bus(USB) device, a coder-decoder (CODEC) chipset, a subscriber identitymodule (SIM) card, and/or a local buffer. The transceiver 214 maycommunicate via wireless communication with networks, such as theInternet, Intranet and/or a wireless network, such as a cellulartelephone network, a wireless local area network (LAN) and/or ametropolitan area network (MAN). The wireless communication may use anyof a plurality of communication standards, protocols, and technologies,such as: Global System for Mobile Communications (GSM), Enhanced DataGSM Environment (EDGE), wideband code division multiple access (W-CDMA),code division multiple access (CDMA), time division multiple access(TDMA), Bluetooth, Light Fidelity (Li-Fi), Wireless Fidelity (Wi-Fi)(e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g and/or IEEE 802.11n),voice over Internet Protocol (VoIP), Wi-MAX, a protocol for email,instant messaging, and/or Short Message Service (SMS).

FIG. 3 is a flowchart that illustrates exemplary operations to controlthe KPI parameters of a transportation system, in accordance with anembodiment. FIG. 3 is described in conjunction with FIG. 1 and FIG. 2.With reference to FIG. 3, there is shown a flowchart 300 thatillustrates a method for controlling the KPI parameters of thetransportation system. The method starts at step 302 and proceeds tostep 304.

At step 304, the historical commuting characteristics of the one or morecommuters are extracted from the database server 106. The historicalcommuting characteristics may comprise the commuting history of the oneor more commuters who may have traveled between at least two locations(or stations) using the one or more transportation services in the past.In an embodiment, the data extracting processor 204 may be configured toextract the historical commuting characteristics from the databaseserver 106. The extraction of the historical commuting characteristicsfrom the database server 106 may be further limited by the first definedtime duration. The service provider of the transportation service mayutilize the service provider-computing device 104 to define the firsttime duration. Based on the first defined time duration, the dataextracting processor 204 may extract the historical commutingcharacteristics that are associated with the first defined timeduration. For example, in an event the service provider defines thefirst time duration as “1 month,” the data extracting processor 204 mayextract the historical commuting characteristics of the last “1 month”from the database server 106. Further, in an embodiment, the historicalcommuting characteristics may be indicative of the source location andthe destination location of each of the one or more commuters. Further,the historical commuting characteristics may be indicative of the one ormore preferences for the one or more transportation services of each ofthe one or more commuters. The historical commuting characteristics maybe further indicative of the frequency of travel of each of the one ormore commuters between one or more pairs of locations or stations. Thehistorical commuting characteristics may be further indicative of othertravel-related constraints of each of the one or more commuters. Forexample, the other travel-related constraints of a commuter may comprisemaximum time duration for travel between the source location and thedestination location, maximum service cost that the commuter may pay forthe travel, and a maximum service capacity of a vehicle. Afterextraction of the historical commuting characteristics of the one ormore commuters, the data extracting processor 204 may store theextracted historical commuting characteristics in a storage device, suchas the database server 106 or the memory 210.

At step 306, the predictive model may be generated based on theextracted historical commuting characteristics of the one or morecommuters. The predictive model may correspond to a random utilitychoice model, such as the MNL model. In an embodiment, the modelgenerating processor 206 may be configured to generate the predictivemodel based on the extracted historical commuting characteristics. Themodel generating processor 206 may employ one or more techniques suchas, but not limited to, one or more statistical techniques, one or morenatural language processing techniques, one or more neural networktechniques, and/or one or more machine learning techniques to generatethe predictive model, for example, the MNL model, based on at least thehistorical commuting characteristics.

Using the MNL choice model, the processor 202, in conjunction with theschedule generating processor 208, optimizes for the service schedulethat may maximize the one or more KPI parameters, for example, the netrevenue, for the service provider. Such optimization for the schedulemay be obtained in two ways. Firstly, when the service provider may haveno restriction on the count or types of the one or more transportationservices to be deployed (i.e., uncapacitated case). Secondly, when theservice provider may have a restriction on the count or types of the oneor more transportation services to be deployed (i.e., capacitated case).For example, the service provider cannot run more than “N” services(possibly due to resource constraints). The above two cases (i.e.,uncapacitated case and capacitated case) have been described in detail,for example, in FIG. 4A and FIG. 4B.

At step 308, the service schedule of the one or more transportationservices for the second defined time duration may be generated, by useof generated predictive model. The service schedule of the one or moretransportation services may correspond to a time table of deploying theone or more transportation services of different service types fromtheir origin location for transit along the one or more routes at theone or more time stamps of the second defined time duration. In anembodiment, the schedule generating processor 208 may be configured togenerate the service schedule of the one or more transportation servicesfor the second defined time duration, by use of at least the generatedpredictive model, for example, the MNL model that captures thehistorical commuting characteristics of the one or more commuters. Theservice schedule of the one or more transportation services for thesecond defined time duration may be further generated based on thedefined criteria of the transportation system. The defined criteria maycomprise the one or more parameters based on at least one of the count,the type, and the capacity of the one or more transportation services.The defined criteria may comprise availability of the one or moretransportation services for travel along the one or more routes duringthe second defined time duration. Further, in an embodiment, the serviceschedule of the one or more transportation services for the seconddefined time duration may be generated based on the service cost fortravel between each pair of locations by each of the one or moretransportation services.

For example, the processor 202 may be configured to generate a commuterpreference vector and a service cost vector. The commuter preferencevector may be generated based on the extracted historical commutingcharacteristics of the one or more commuters. Each numerical value inthe commuter preference vector may indicate a degree of preference ofthe one or more commuters for travel along the one or more routes by theone or more transportation services. The service cost vector may begenerated based on the service cost associated with each of the one ormore transportation services. The travel costs in the generated servicecost vector may be arranged in a decreasing order. Based on thegenerated commuter preference vector and service cost vector, theschedule generating processor 208 may generate the service schedule ofthe one or more transportation services. The schedule generatingprocessor 208 may further store the generated service schedule in thestorage device, such as the database server 106 or the memory 210. Inanother embodiment, the schedule generating processor 208 may presentthe generated service schedule at the GUI rendered on the display screenof the service provider-computing device 104.

At step 310, the one or more KPI parameters of the transportation systemmay be controlled to attain the optimized values, when the one or moretransportation services may be deployed based on the generated serviceschedule. The optimized values may correspond to the one or more desiredKPI parameters that may be essential for the growth and success of thetransportation system, as well as comfort and satisfaction of the one ormore commuters. In an embodiment, the processor 202 may be configured tocontrol the one or more KPI parameters to attain the optimized values.The one or more KPI parameters may be controlled, when the one or moretransportation services have been deployed for transit at a time stampin the second user-defined time duration, based on the generated serviceschedule.

At step 312, the real-time feedback data may be received from theservice provider-computing device 104 over the communication network110. The received real-time feedback data may correspond to thecontrolled one or more KPI parameters, when the one or moretransportation services have been deployed at the time stamp in thesecond defined time duration. The processor 202 may be configured toreceive the real-time feedback data from the service provider-computingdevice 104 over the communication network 110. The service provider mayprovide the real-time feedback data in an event the current one or moreKPI parameters are below the one or more desired KPI parameters. Theprocessor 202 may store the received real-time feedback data in thestorage device, such as the database server 106 or the memory 210.

At step 314, the generated predictive model may be updated based on thereceived real-time feedback data. The model generating processor 206 maybe configured to update the generated predictive model based on thereceived real-time feedback data to obtain an updated predictive model,for example, an updated MNL model.

At step 316, the generated service schedule of the one or moretransportation services may be updated based on the updated predictivemodel. In an embodiment, the schedule generating processor 208 may beconfigured to update the generated service schedule for the one or moreother time stamps in the second defined time duration, based on theupdated predictive model. The generated service schedule may be updatedsuch that the one or more KPI parameters attain at least the optimizedvalues. Based on the updated service schedule, the service provider maydeploy the one or more transportation services at the one or more othertime stamps in the second defined time duration for transit along theone or more routes. Control passes to end step 318.

A person having ordinary skills in the art will understand that theabovementioned exemplary operations are for illustrative purpose andshould not be construed to limit the scope of the disclosure. Further,the abovementioned exemplary operations may be implemented or executedin two settings, for example, an offline setting and an online setting.In the offline setting, the extracted historical commutingcharacteristics of the one or more commuters are taken as an input togenerate the predictive model, such as the MNL model, that may befurther utilized to generate the service schedule that maximizes the oneor more KPI parameters for the service provider. In the online setting,the service schedule may be generated for the one or more time stamps ofthe second defined time duration. Further, the one or moretransportation services may be deployed for transit at a time stamp ofthe one or more time stamps, based on the generated service schedule. Inresponse to such deployment, the processor 202 may receive the real-timefeedback data in terms of the net revenue collected or any other KPIparameter for the time stamp. Based on the received real-time feedbackdata, the predictive model may be updated and thereafter, determines newschedules that can be deployed in the one or more other time stamps thatpotentially may lead to higher revenues/KPI. The abovementionedexemplary operations for the offline setting have been described, forexample, in FIG. 4A. Similarly, the abovementioned exemplary operationsfor the online setting have been described, for example, in FIG. 4B.

FIG. 4A is a block diagram that illustrates an exemplary scenario tocontrol the KPI parameters of a transportation system in an offlinesetting, in accordance with at least one embodiment. FIG. 4A has beendescribed in conjunction with FIG. 1, FIG. 2, and FIG. 3. With referenceto FIG. 4A, there is shown exemplary block diagrams, such as a datacollection block 402, a choice modeling block 404, and a schedulegeneration and optimization block 406, as shown.

The data collection block 402 comprises the historical commutingcharacteristics (of the one or more commuters) that may be extracted bythe data extracting processor 204 from the database server 106. Theprocessor 202 may further output the historical commutingcharacteristics from the data collection block 402 to the choicemodeling block 404. The model generating processor 206 may construct thepredictive model (e.g., the MNL model) based on the historical commutingcharacteristics. The predictive model may be indicative of a conditionaldistribution of the historical commuting characteristics of the one ormore commuters. Further, the processor 202 may output the generatedpredictive model to the schedule generation and optimization block 406.The schedule generating processor 208 may generate the service scheduleof the one or more transportation services using the generatedpredictive model, for example, the MNL model. By use of the MNL model inthe schedule generation, the service schedule may be optimized such thatthe one or more KPI parameters, for example, net revenue or net profit,for the service provider may be maximized. Such optimization of theservice schedule may be obtained in two ways, for example, anunconstrained case and a constrained case.

Offline Optimization: Uncapacitated Case

In an embodiment, the optimal assortment for the uncapacitatedassortment optimization problem with the MNL model is revenue orderedset. Let the one or more transportation services (of different types,timings, and/or prices) be indexed from “1” to “n” in the decreasingorder of prices. Then, the revenue ordered set may be a set, S={1, 2, .. . , j}, for some j. Thus, instead of 2^(n) assortments in the serviceschedule, the processor 202 may look for the optimal assortment only in“n” revenue ordered assortments, where n is the number of transportationservices. In such cases, the revenue of the revenue ordered assortmentsmay be weakly unimodal. This property may enable the use of fastersearch algorithms, such as Golden Section Search, and hence, obtain theoptimal revenue ordered assortment in time O(log n).

Let the commuter preference vector be represented as v=v₀, v₁, . . . ,v_(n) and the service cost vector be represented as p=p₁, p₂, . . . ,p_(n). Further, assume that the transportation services have alreadybeen sorted in the decreasing order of their prices. Let f(A,v) denotethe revenue of the set A of transportation services. Thus, based on theMNL model,

$\begin{matrix}{{f\left( {A,v} \right)} = \frac{\sum\limits_{l \in A}{p_{l}v_{l}}}{v_{0} + {\sum\limits_{l \in A}v_{l}}}} & (1)\end{matrix}$Let g(i, v) denote the revenue of the set {1, 2, . . . i} when thecommuter preference vector is v.Thus,

$\begin{matrix}{{g\left( {i,v} \right)} = {{f\left( {\left\{ {1,2,{\ldots\mspace{14mu} i}} \right\},v} \right)} = \frac{\sum\limits_{j = 1}^{i}{p_{j}v_{j}}}{\sum\limits_{j = 0}^{i}v_{j}}}} & (2)\end{matrix}$Offline Optimization: Capacitated Case

The assortment optimization problem with a capacity constraint (C) doesnot offer the same structural properties as the uncapacitated problem.The currently known algorithm to solve this problem has time complexityO(n² log n). Thus, due to advancement in linear programming codingtechniques, the processor 202 may utilize the linear programming methodto obtain the optimal assortment for the capacitated assortmentoptimization problem with the MNL model. The key feature of the linearprogramming method is its low computation complexity making it suitablefor applications with large number of transportation services. Further,such a method may take limited time to compute the optimal assortment.For example, the revenue optimization problem may be naively written asan integer non-linear program as follows:

$\begin{matrix}{\max\frac{\sum\limits_{i = 1}^{n}{p_{i}v_{i}x_{i}}}{v_{0} + {\sum\limits_{i = 0}^{n}{v_{i}x_{i}}}}} & (3)\end{matrix}$such that,Σ_(i=1) ^(n) x _(i) <C and x _(i)∈{0,1}.

Here x_(i) is the decision variable that indicates whether thetransportation service i should be included in the optimal assortment ornot. It turns out that the following linear programming reformulationwithout integer constraints is equivalent to the above problem:max Σ_(i=1) ^(n) p _(i) z _(i)  (4)such that,

${{z_{0} + {\sum\limits_{i = 1}^{n}z_{i}}} = 1};$${{\sum\limits_{i = 1}^{n}\frac{z_{i}}{v_{i}}} \leq {\frac{z_{0}}{v_{0}}C}};{and}$$0 \leq \frac{z_{i}}{v_{i}} \leq {\frac{z_{0}}{v_{0}}\mspace{14mu}{\forall{i \in \lbrack n\rbrack}}}$

The variables here are z_(i) that are continuous valued. In fact thesequantify a likelihood of purchase, i.e.,

$z_{i} = {\frac{v_{i}x_{i}}{v_{0} + {\sum\limits_{j}{v_{j}x_{j}}}}.}$Thus, given a solution of {z₀, z₁, . . . , z_(n)}, the processor 202 mayeasily find the assortment solution {x₁, . . . , x_(n)}. Further, thislinear program may be efficiently solved using off-the-shelf LP solvers,such as CPLEX, very efficiently for even large assortment optimizationinstances.

FIG. 4B is a block diagram that illustrates an exemplary scenario tocontrol the KPI parameters of a transportation system in an onlinesetting, in accordance with at least one embodiment. FIG. 4B has beendescribed in conjunction with FIG. 1, FIG. 2, and FIG. 3. With referenceto FIG. 4B, there is shown an exemplary block diagram to illustrate theexemplary operations in the online setting. For example, given thechoice model, for example, the MNL model, the KPI optimizing schedulemay be obtained (denoted by 408). The schedule generating processor 208may generate the service schedule that may optimize the one or more KPIparameters. Based on the service schedule, the one or moretransportation services may be deployed (denoted by 410). The one ormore transportation services may be deployed for transit along the oneor more routes at a time stamp of the one or more time stamps in thesecond defined time duration. Further, the one or more KPI parametersmay be monitored on the service provider-computing device 104. Theprocessor 202 may measure the one or more KPI parameters (denoted by412). Further, the processor 202 may display the measure of the one ormore KPI parameters on the display screen of the serviceprovider-computing device 104. Based on the measured one or more KPIparameters, the MNL model may be updated (denoted by 414). Thereafter,the schedule generating processor 208 may update the service schedulefor the one or more other time stamps in the second defined timeduration. Based on the updated service schedule, the service providermay deploy the one or more transportation services at the one or moreother stamps so as to attain enhanced growth in terms of the one or moreKPI parameters. Such optimization of the service schedule may beobtained in two ways, for example, an unconstrained case and aconstrained case.

Online Optimization: Uncapacitated Case

In the online setting where the commuters' commuting characteristics arebeing learnt and the optimal assortment of the service schedule needs tobe presented in real time in accordance with the latest estimates, theassortment optimization problem may need to be solved repeatedly as theone or more KPI parameters are updated. In such cases, the processor 202may update at most one parameter in one iteration. The processor 202 mayevaluate intervals around the current parameters in which the optimalassortment remains the same after the update. The processor 202 mayfurther evaluate the new optimal assortment for all possible values ofchange in any one of the parameters. For the below discussion, thefollowing assumptions have been made: Firstly, the service prices of allthe transportation services are distinct. Secondly, all the componentsof the commuter preference vector are non-zero.

Let the estimate of the commuter preference vector at the beginning ofthe t^(th) round be v^(t). Let the index of the component updated at theend of the t^(th) round be k_(t). Thus,

$\begin{matrix}{{v_{i}^{t} = {v_{i}^{t - 1} + \delta_{t}}},} & {{{if}\mspace{14mu} i} = k_{t - 1}} \\{{= v_{i}^{t - 1}},} & {otherwise}\end{matrix}$${where},{\delta_{t} > {- {v_{i}^{t - 1}.{Now}}}},{{g\left( {i,v} \right)} = {\frac{\sum\limits_{i = 1}^{i}{p_{i}v_{i}}}{\sum\limits_{i = 0}^{i}v_{i}}.{Thus}}},{{g\left( {i,v^{t}} \right)} = {{{g\left( {i,v^{t - 1}} \right)}\mspace{14mu}{if}\mspace{14mu} i} < {k_{t - 1}.}}}$

As the optimal assortment in every round is a revenue orderedassortment, let the optimal assortment in the t^(th) round be 1, 2, . .. , j_(t)*. If j_(t-1)*<k_(t-1)−1, then g(i,v^(t))=g(i,v^(t-1)) fori<j_(t-1)*+1.

Further, in an event j_(t-1)*<k_(t-1)−1, the following inequalities(denoted by equations 5 and 6) must be satisfied:δ_(t-1)(p _(j) _(t-1) _(*) −p _(k) _(t-1) )1(k _(t-1) ≤j_(t-1)*−1)>Σ_(i=0) ^(j) ^(t-1) ^(*−1)(p _(i) −p _(j) _(t-1) _(*))v _(i)^(t-1)  (5)δ_(t-1)(p _(1+j) _(t-1) _(*) −p _(k) _(t-1) )1(k _(t-1) ≤j_(t-1)*)≤Σ_(i=0) ^(j) ^(t-1) ^(*)(p _(i) −p _(1+j) _(t-1) _(*))v _(i)^(t-1)  (6)where,

1(·) represents the indicator function.

In the event that δ_(t-1) may not lie in an interval specified by theequations (5) and (6), the processor 202 may have to search for theoptimal assortment after the commuter preference vector has been updatedfrom v_(t-1) to v_(t). Further, if equation (5) is satisfied (i.e.,holds true), then g(j_(t-1)*−1, v^(t))<g(j_(t-1)*,v^(t)) andj_(t)*≥j_(t-1)* and vice-versa, i.e., if equation (5) is not satisfied,then j_(t)*<j_(t-1)*. Similarly, if equation (6) is satisfied (i.e.,holds true), then g(j_(t-1)*,v^(t))>g(j_(t-1)*+1, v^(t)) andj_(t)*≤j_(t-1)* and vice-versa. Such observations may be utilized by theprocessor 202 to narrow down the search space for the optimal revenueordered assortment.

In the above discussion, the conditions are described under which theoptimal assortment may remain same after the commuter preference vectormay have been updated. Using the same approach, the conditions underwhich the optimal assortment characterized by j_(t)* that may take aparticular value have been mentioned below: Let j_(t)*=j_(t-1)*+m_(t).Thus, p_(j) _(t) _(*)>g(j_(t)*−1,v^(t)) and p_(1+j) _(t)_(*)≤g(j_(t)*,v^(t)).

The first condition implies that:δ_(t-1)(p _(j) _(t-1) _(*+m) _(t) −p _(k) _(t-1) )1(k _(t-1) ≤j _(t-1)*+m _(t)−1)>Σ_(i=0) ^(j) ^(t-1) ^(*+m) ^(t) ⁻¹(p _(i) −p _(j) _(t-1)_(*+m) _(t) )v _(i) ^(t-1)  (7)The second condition implies that:δ_(t-1)(p _(j) _(t-1) _(*+m) _(t) −p _(k) _(t-1) )1(k _(t-1) ≤j _(t-1)*+m _(t))≤Σ_(i=0) ^(j) ^(t-1) ^(m) ^(t) (p _(i) −p _(1+j) _(t-1) _(*+m)_(t) )v _(i) ^(t-1)  (8)Online Optimization: Capacitated Case

The sensitivity analysis for the assortment optimization problem withconstraints having unimodular constraint structures, such as capacityconstraints, precedence constraints, constraints on quality consistentpricing, may be formulated as a set of unimodular constraints. Such aproblem may be formulated as a linear program. Based on the update inone of the choice parameters, an entire column of the constraint matrixof the linear program may change. The processor 202 may be configured toexecute the sensitivity analysis under such changes and derive a rangeof parameters under which the optimal assortment may remain unchanged.The following linear program may be utilized to find the optimalassortment with the unimodular constraints:max Σ_(j∈N) p _(j) w _(i)  (9)such that,

${{{\sum\limits_{j \in N}w_{j}} + w_{0}} = 1};$${{\sum\limits_{j \in N}{d_{ij}\frac{w_{j}}{v_{j}}}} \leq {b_{i}w_{0}\mspace{14mu}{\forall{i \in M}}}};{and}$$0 \leq \frac{w_{j}}{v_{j}} \leq {w_{0}\mspace{14mu}{\forall{j \in {N.}}}}$where the feasible offer set is given by F={x∈{0,1}^(|N|): Σ_(j∈N)d_(ij)x_(j)≤b_(i)∀i∈M}, and x_(i)=1(0) may represent the i^(th)transportation service that is offered (not offered) in the assortment.The ij^(th) entry of the constraint matrix of the above linear programin the t^(th) iteration may be represented as a_(ij)(t). Let the size ofthe constraint matrix be e×f. In an event the update is made in thecommuter preference vector v, multiple entries of the constraint matrixof the above linear program may change. Note that if in the t^(th)round, the k_(t) ^(th) component of v^(t) is updated, then only entriesof the k_(t) ^(th) column in the constraint matrix may change. Thepermissible intervals for any component of v may depend on whether thecomponent is a basic variable or not in the basic feasible solution ofthe linear program. To simplify notation, it may be assumed that thefirst e variables are the basic variables. Let the reduced costs of thevariables at the end of (t−1)^(th) round be r(t−1)=<r^(l)(t−1):l=1, 2, .. . f>. Further, let the elements of the inverse of the basis matrix beb_(ij) (i,j=1, 2, . . . , m). Let's consider a case when the k_(t-1)^(th) variable may be a non-basic variable. For each element a_(il) ofthe constraint matrix (where x_(l) is a non-basic variable), theprocessor 202 may determine a range of values such that the new reducedcost of all the variables still remains non-positive. Thus,r_(l)(t−1)−Δa_(il)Σ_(j=1) ^(m)p_(j)b_(ji)≤0, whereΔa_(il)=a_(il)(t)−a_(il)(t−1). This may result in a range of acceptablevalues of Δa_(il). The range may be denoted by [−L_(il), U_(il)].Further, Δa_(il)* and λ_(i) may be defined as follows:

${\Delta\; a_{il}^{*}} = \left\{ {\begin{matrix}U_{i\; l} & {{{if}\mspace{14mu}\Delta\; a_{il}} > 0} \\{- L_{il}} & {{{if}\mspace{14mu}\Delta\; a_{il}} < 0} \\0 & {{{if}\mspace{14mu}\Delta\; a_{il}} = 0}\end{matrix},{\lambda_{i} = \left\{ \begin{matrix}\frac{\Delta\; a_{il}}{\Delta\; a_{il}^{*}} & {{{if}\mspace{14mu}\Delta\; a_{il}} \neq 0} \\0 & {otherwise}\end{matrix} \right.}} \right.$

In the event of Δa_(il)∈[−L_(il), U_(il)]∀i∈[1,f] and Σ_(i=1)^(e)λ_(i)≤1, the optimal basis of the updated linear program may be sameas that of the original linear program. Moreover, the optimal revenueand the revenue-maximizing assortment remains the same. Thus, for agiven change in the commuter preference vector v, the changes in theconstraint matrix may be computed. If the change in the constraintmatrix satisfies the above conditions, the optimal assortment remainsunchanged.

Further, considering the case when the k_(t-1) ^(th) component is abasic variable in the optimal solution of the linear program at the(t−1)^(th) iteration, the i^(th) column of the inverse of the basismatrix may be denoted by b′ of the optimal solution obtained at the endof the (t−1)^(th) iteration. Also, let the optimal solution at the endof the (t−1)^(th) iteration be w*(t−1)=(w*(t−1)_(B)w*(t−1)_(N), wherew*(t−1)_(B) and w*(t−1)_(N) may represent the basic and non-basiccomponents, respectively. For each element a_(il), a range of values forwhich the current solution remains feasible and optimal may be given bythe following conditions:M=1+b _(ij) Δa _(il)>0;Mw*(t−1)_(B) −Δa _(il) w*(t−1)_(l) b ^(i)≥0; andMr _(j)(t−1)+a _(lj) *Δa _(jl)(Σ_(s=1) ^(e) p _(s) b _(si))≤0 fore+1≤j≤f.

The above conditions may determine the range of Δa_(il), denoted by[−L_(il), U_(il)] that may be defined as discussed above. In the eventof Δa_(il)∈[−L_(il), U_(il)]∀i∈[1,f] and Σ_(i=1) ^(e) λ_(i)≤1, theoptimal basis of the updated linear program may be same as that of theoriginal linear program.

Regret Minimizing Online Optimization:

Given a set N of n products and a capacity C, the assortmentoptimization problem is to look for the best possible assortment S⊂Nsuch that |S|<C and the associated revenue is as large as possible. Inthis section, a parallelism has been drawn between the assortmentoptimization problem and the multi-armed bandit (MAB) problem. Thedifferent possible assortments represent the different arms of the MAB.Each of the arms may be associated with a reward. In each round, theprocessor 202 may select an arm (assortment), and thereafter, presentthe selected arm to the commuter. Based on what the commuter chooses,the processor 202 may compute the revenue. At a particular round, theprocessor 202 may have no information with regard to the revenue whensome other arm is chosen. It is thus a Semi-Bandit setting. In thiscase, let a_(t) denote the arm chosen. Then, the revenue received forchosen arm may be y_(t)[a_(t)]. Here, the goal is to have low regret fornot always pulling the best arm, i.e. not always showing the optimalassortment. In scenarios when instead of ‘at-most C’ products, exactly Cproducts are shown, the total number of arms is thus N choose C. As inthe rest of the disclosure, the MNL Choice Model has been used tocharacterize the behavior of the commuter. Specifically if the commuterpreference vector is given by v=[v₁, . . . , v_(n)], then given anassortment A, the likelihood of choosing a product i∈A is given by,

${{P\left( {{product}\mspace{14mu} i\mspace{14mu}{chosen}} \right)} = \frac{v_{i}}{v_{0} + {\sum\limits_{l \in \mathcal{A}}v_{l}}}},$where v₀ may correspond to no product being selected. If the pricesassociated with the products are p₁, p₂, . . . , p_(n), then theexpected revenue is given by

${f\left( {\mathcal{A},v} \right)} = {\frac{\sum\limits_{l \in \mathcal{A}}{p_{l}v_{l}}}{v_{0} + {\sum\limits_{l \in \mathcal{A}}v_{l}}}.}$

Further, in an embodiment, the processor 202, in conjunction with theschedule generating processor 208, may be configured to generate aregret minimizing service schedule in an event the true underlyingcommuter choice behavior may not be known in advance and may be learnedvia feedback. A known algorithm, such as an Online Mirror Descent (OMD)algorithm, may be used to achieve the regret minimizing serviceschedules.

The disclosed embodiments encompass numerous advantages. The disclosureprovides a method and a system for controlling KPI parameters of thetransportation system. The disclosed method maximizes the revenue andother key performance indicators for the service provider of thetransportation systems by taking commuter choice behavior in to accountand also by learning the changing commuter choice behaviors over aperiod of time. This may be applicable when the transportation servicesare differently priced and the commuters have alternate commutingchoices. The disclosure assumes a commuter choice model (e.g., theMultinomial Logit model) and gives an optimal offline algorithm tooptimize the revenue and other key performance indicators when theservice provider has no restriction on the number of services of eachtype that may be deployed. When the capacity is limited, the disclosureproposes an approximate algorithm for optimizing the revenue and otherkey performance indicators that is faster and scalable as compared toexisting approaches. The disclosure also proposes a sensitivityanalysis-based scheme for adjusting the schedules to choice parametersbeing estimated and updated in real time. The sensitivity analysis-basedscheme prevents re-solving the revenue optimized scheduling problemunless the effect is significant, and hence minimizes wastage ofcomputational resources. Finally, the disclosure proposes anexplore-exploit based method to learn commuter choices and find theoptimal schedule. This can also be deployed as an adaptive system toadapt the schedules to changing commuter choices over time.

The disclosed methods and systems, as illustrated in the ongoingdescription or any of its components, may be embodied in the form of acomputer system. Typical examples of a computer system include ageneral-purpose computer, a programmed microprocessor, amicro-controller, a peripheral integrated circuit element, and otherdevices, or arrangements of devices that are capable of implementing thesteps that constitute the method of the disclosure.

The computer system comprises a computer, an input device, a displayunit, and the internet. The computer further comprises a microprocessor.The microprocessor is connected to a communication bus. The computeralso includes a memory. The memory may be RAM or ROM. The computersystem further comprises a storage device, which may be a HDD or aremovable storage drive such as a floppy-disk drive, an optical-diskdrive, and the like. The storage device may also be a means for loadingcomputer programs or other instructions onto the computer system. Thecomputer system also includes a communication unit. The communicationunit allows the computer to connect to other databases and the internetthrough an input/output (I/O) interface, allowing the transfer as wellas reception of data from other sources. The communication unit mayinclude a modem, an Ethernet card, or other similar devices that enablethe computer system to connect to databases and networks, such as, LAN,MAN, WAN, and the internet. The computer system facilitates input from auser through input devices accessible to the system through the I/Ointerface.

To process input data, the computer system executes a set ofinstructions stored in one or more storage elements. The storageelements may also hold data or other information, as desired. Thestorage element may be in the form of an information source or aphysical memory element present in the processing machine.

The programmable or computer-readable instructions may include variouscommands that instruct the processing machine to perform specific tasks,such as steps that constitute the method of the disclosure. The systemsand methods described can also be implemented using only softwareprogramming or only hardware, or using a varying combination of the twotechniques. The disclosure is independent of the programming languageand the operating system used in the computers. The instructions for thedisclosure can be written in all programming languages, including, butnot limited to, ‘C’, ‘C++’, ‘Visual C++’ and ‘Visual Basic’. Further,software may be in the form of a collection of separate programs, aprogram module containing a larger program, or a portion of a programmodule, as discussed in the ongoing description. The software may alsoinclude modular programming in the form of object-oriented programming.The processing of input data by the processing machine may be inresponse to user commands, the results of previous processing, or from arequest made by another processing machine. The disclosure can also beimplemented in various operating systems and platforms, including, butnot limited to, ‘Unix’, ‘DOS’, ‘Android’, ‘Symbian’, and ‘Linux’.

The programmable instructions can be stored and transmitted on acomputer-readable medium. The disclosure can also be embodied in acomputer program product comprising a computer-readable medium, or withany product capable of implementing the above methods and systems, orthe numerous possible variations thereof.

Various embodiments of the methods and systems for controlling KPIparameters of a transportation system have been disclosed. However, itshould be apparent to those skilled in the art that modifications inaddition to those described are possible without departing from theinventive concepts herein. The embodiments, therefore, are notrestrictive, except in the spirit of the disclosure. Moreover, ininterpreting the disclosure, all terms should be understood in thebroadest possible manner consistent with the context. In particular, theterms “comprises” and “comprising” should be interpreted as referring toelements, components, or steps, in a non-exclusive manner, indicatingthat the referenced elements, components, or steps may be present, orused, or combined with other elements, components, or steps that are notexpressly referenced.

A person with ordinary skills in the art will appreciate that thesystems, modules, and sub-modules have been illustrated and explained toserve as examples and should not be considered limiting in any manner.It will be further appreciated that the variants of the above disclosedsystem elements, modules, and other features and functions, oralternatives thereof, may be combined to create other different systemsor applications.

Those skilled in the art will appreciate that any of the aforementionedsteps and/or system modules may be suitably replaced, reordered, orremoved, and additional steps and/or system modules may be inserted,depending on the needs of a particular application. In addition, thesystems of the aforementioned embodiments may be implemented using awide variety of suitable processes and system modules, and are notlimited to any particular computer hardware, software, middleware,firmware, microcode, and the like.

The claims can encompass embodiments for hardware and software, or acombination thereof.

It will be appreciated that variants of the above disclosed, and otherfeatures and functions or alternatives thereof, may be combined intomany other different systems or applications. Presently unforeseen orunanticipated alternatives, modifications, variations, or improvementstherein may be subsequently made by those skilled in the art, which arealso intended to be encompassed by the following claims.

What is claimed is:
 1. A method for deploying transportation services ofa transportation system, said method comprising: extracting, by a dataextracting processor at a computing server, historical commutingcharacteristics of one or more commuters, from a database server over acommunication network, based on a first user-defined time duration;generating, by a model generating processor at said computing server, apredictive model based on said extracted historical commutingcharacteristics of said one or more commuters, wherein said predictivemodel comprises a commuter preference vector and a service cost vectorand generating said predictive model comprises generating the commuterpreference vector and the service cost vector; generating, by theschedule generating processor at said computing server, a serviceschedule of one or more transportation services of said transportationsystem for a second user-defined time duration, by use of said generatedpredictive model, based on defined criteria of said transportationsystem and based on the commuter preference vector and the service costvector; providing, via a communication network, the service schedule toone or more service provider computing devices of one or more serviceproviders associated with the transportation system; deploying one ormore of the transportation services to travel along one or more routesduring the second user-defined time duration according to the serviceschedule; receiving, from one or more of the service provider computingdevices associated with the deployed transportation services, via thecommunication network, real time feedback of a KPI parameter associatedwith the deployed transportation services; and in response to receivingthe real time feedback, updating the predictive model and determiningwhether to generate an updated service schedule to attain a desired KPIparameter for the transportation system by: determining an intervalwithin which the commuter preference vector may change without affectingan assortment selected by the predictive model; updating the predictivemodel by determining an updated commuter preference vector based on thereal-time feedback of the KPI parameter associated with the deployedtransportation services; and determining, based on whether an amount ofchange from the commuter preference vector to the updated commuterpreference vector is within the determined interval, whether to generatean updated service schedule based on the updated commuter preferencevector.
 2. The method of claim 1, wherein said historical commutingcharacteristics of said one or more commuters depends on at least one ofa source location, a destination location, a travel time, a travel cost,a service capacity, and a travel route.
 3. The method of claim 1,wherein said KPI parameter associated with the deployed transportationservices corresponds to at least one of a net revenue generated by saiddeployment of said one or more transportation services along one or moreroutes, a net profit of said transportation system based on saiddeployment of said one or more transportation services, and a count ofcommuters carried by said one or more transportation services.
 4. Themethod of claim 1, wherein said generation of said commuter preferencevector is based on said extracted historical commuting characteristicsof said one or more commuters.
 5. The method of claim 1, wherein saidgeneration of said service cost vector is based on a travel costassociated with each of said one or more transportation services of saidtransportation system, wherein a plurality of travel costs in saidservice cost vector are arranged in a decreasing order.
 6. The method ofclaim 1, wherein said predictive model corresponds to a random utilitychoice model that captures commuting characteristics of said one or morecommuters.
 7. The method of claim 1, wherein said defined criteriacomprise one or more parameters based on at least one of a count, atype, and a capacity of said one or more transportation services to bedeployed by said transportation system during said second user-definedtime duration.
 8. A system for deploying transportation services of atransportation system, said system comprising: a data extractingprocessor configured to extract historical commuting characteristics ofone or more commuters, from a database server over a communicationnetwork, based on a first user-defined time duration; a model generatingprocessor configured to generate a predictive model based on saidextracted historical commuting characteristics of said one or morecommuters, wherein said predictive model comprises a commuter preferencevector and a service cost vector and generating said predictive modelcomprises generating the commuter preference vector and the service costvector; a schedule generating processor configured to generate a serviceschedule of one or more transportation services of said transportationsystem for a second user-defined time duration, by use of said generatedpredictive model, based on defined criteria of said transportationsystem and based on the commuter preference vector and the service costvector; and a processor configured to provide, via a communicationnetwork, the service schedule to one or more service provider computingdevices of one or more service providers associated with thetransportation system; deploy one or more of the transportation servicesto travel along one or more routes during the second user-defined timeduration according to the service schedule; receive, from one or more ofthe service provider computing devices associated with the deployedtransportation services, via the communication network, real timefeedback of a KPI parameter associated with the deployed transportationservices; and in response to receiving the real time feedback, updatethe predictive model and determine whether to generate an updatedservice schedule to attain a desired KPI parameter for thetransportation system by: determining an interval within which thecommuter preference vector may change without affecting an assortmentselected by the predictive model; updating the predictive model bydetermining an updated commuter preference vector based on the real-timefeedback of the KPI parameter associated with the deployedtransportation services; and determining, based on whether an amount ofchange from the commuter preference vector to the updated commuterpreference vector is within the determined interval, whether to generatean updated service schedule based on the updated commuter preferencevector.
 9. The system of claim 8, wherein said historical commutingcharacteristics of said one or more commuters depends on at least one ofa source location, a destination location, a travel time, a travel cost,a service capacity, and a travel route.
 10. The system of claim 8,wherein said generation of said commuter preference vector is based onsaid extracted historical commuting characteristics of said one or morecommuters.
 11. The system of claim 8, wherein said generation of saidservice cost vector is based on a travel cost associated with each ofsaid one or more transportation services of said transportation system,wherein a plurality of travel costs in said service cost vector arearranged in a decreasing order.
 12. The system of claim 8, wherein saidgeneration of said service schedule is based on at least said commuterpreference vector and said service cost vector.
 13. The system of claim8, wherein said predictive model corresponds to a random utility choicemodel that captures commuting characteristics of said one or morecommuters.
 14. The system of claim 8, wherein said defined criteriacomprise one or more parameters based on at least one of a count, atype, and a capacity of said one or more transportation services to bedeployed by said transportation system during said second user-definedtime duration.
 15. A computer program product for use with a computer,said computer program product comprising a non-transitory computerreadable medium, wherein said non-transitory computer readable mediumstores a computer program code for deploying transportation services ofa transportation system, wherein said computer program code isexecutable by one or more processors in a computing device to: extracthistorical commuting characteristics of one or more commuters, from adatabase server over a communication network, based on a firstuser-defined time duration; generate a predictive model based on saidextracted historical commuting characteristics of said one or morecommuters, wherein said predictive model comprises a commuter preferencevector and a service cost vector and generating said predictive modelcomprises generating the commuter preference vector and the service costvector; generate a service schedule of one or more transportationservices of said transportation system for a second user-defined timeduration, by use of said generated predictive model, based on definedcriteria of said transportation system and based on the commuterpreference vector and the service cost vector; provide, via acommunication network, the service schedule to one or more serviceprovider computing devices of one or more service providers associatedwith the transportation system to facilitate deployment of one or moreof the transportation services according to the service schedule;receive, from one or more of the service provider computing devicesassociated with transportation services that are deployed according tothe service schedule during the second user-defined time duration, viathe communication network, real time feedback of a KPI parameterassociated with the one or more of the transportation services that aredeployed during the second user-defined time duration according to theservice schedule; and in response to receiving the real time feedback,update the predictive model and determine whether to generate an updatedservice schedule to attain a desired KPI parameter for thetransportation system by: determining an interval within which thecommuter preference vector may change without affecting an assortmentselected by the predictive model; updating the predictive model bydetermining an updated commuter preference vector based on the real-timefeedback of the KPI parameter associated with the deployedtransportation services; and determining, based on whether an amount ofchange from the commuter preference vector to the updated commuterpreference vector is within the determined interval, whether to generatean updated service schedule based on the updated commuter preferencevector.
 16. The method of claim 1, further comprising, in response todetermining that the amount of change from the commuter preferencevector to the updated commuter preference vector is outside thedetermined interval, using the predictive model to generate an updatedservice schedule based on the updated commuter preference vector. 17.The method of claim 1, further comprising in response to determiningthat the amount of change from the commuter preference vector to theupdated commuter preference vector is within the determined interval,refraining from generating an updated service schedule based on theupdated commuter preference vector.
 18. The system of claim 8, whereinthe processor is configured to, in response to determining that theamount of change from the commuter preference vector to the updatedcommuter preference vector is outside the determined interval, use thepredictive model to generate an updated service schedule based on theupdated commuter preference vector.
 19. The method of claim 1, furthercomprising, in response to determining that the amount of change fromthe commuter preference vector to the updated commuter preference vectoris within the determined interval, refraining from generating an updatedservice schedule based on the updated commuter preference vector.